How exactly does an Ethernet collision happen in the cable, since nodes use different circuits for Tx and Rx?

Question

I am trying to understand how a collision occurs in Ethernet, especially when a duplex mismatch exists or when on a legacy Ethernet network two nodes transmit simultaneously.

Everyone explains the collision in an upper level (two frames collide when the one is being sent and the other is being received). However, the graph below shows that there are different circuits for Rx and Tx. How a collision can happen since there are dedicated circuits for sending and receiving frames?

EDIT: Maybe the label "Hub MDI-X" causes some confusion regarding the point of my question. I am not asking how the functionallity of a hub can cause collision. My focus is on the communicaton between two nodes with either MDI or MDI-X interfaces (hub and switches have MDI-X interfaces). In any of these two cases, how a collision can happen between two nodes when they have duplex mismatch, whilst in duplex mismatch Rx and Tx have still their dedicated circuits?

Answer 1

To understand this you need to understand the historical context.

Originally Ethernet used a shared coaxial cable. Only one device could successfully transmit on this at a time. If two devices transmitted at the same time it was considered a collision.

Then repeaters came along, to extend the distance and increase the number of nodes. A repeater would detect which port is transmitting, then it would repeat that signal out on the other ports. To keep the collision detection working repeaters had to have some functionality for ensuring that all nodes detected a collision. The first repeaters only had two ports, but later repeaters could have multiple ports and these became known as hubs, especially when used in conjunction with twisted-pair wiring. Repeaters were pretty dumb devices, they would regenerate the electrical signals but little more.

Then 10BASE-T came in, which as you have noticed has dedicated data channels for each direction. Nevertheless it still needed to fit into the existing model, so by default it operated in a "half-duplex" mode where it emulated a coaxial cable. The signals did not in-fact collide on the wire but the transceivers acted as-if they did and the repeaters would take the same steps as before to ensure this was seen across the network.

Twisted pair Ethernet can also support a "full-duplex" mode. In this mode all of the collision-related hardware is disabled and both ends can transmit at any time. However this mode brought a couple of major downsides.

• It was incompatible with repeater-hubs. Without the collision detection mechanisms hubs would have no way of handling two devices transmitting at the same time.
• Both ends of a link to be set-up for the same duplex mode, if they are not then bad things will happen.

These issues meant that in practice 10BASE-T systems nearly always operated in half-duplex mode.

For 100BASE-TX the situation improved dramatically. Ethernet switches (technically fast multi-port bridges) came down in price to the point that dumb repeater hubs could be eliminated. Auto-negotiation allowed network cards to establish full-duplex connections without error-prone manual configuration. If you connect two 100BASE-TX NICs together with a crossover cable or connect a 100BASE-TX NIC to a switch and don't take steps to manually override things they will almost certainly negotiate full-duplex mode.

1000BASE-T theoretically has a half-duplex mode which some NICs claim to support and there was a specification for gigabit multiport repeaters, but I have never seen any evidence that anyone ever sold one. In practice a gigabit link will almost-certainly be running in full-duplex mode.

Faster speeds abandoned the half-duplex mode entirely.

Answer 2

A hub is really just a powered cable that repeats every signal it receives on one interface to all the other interfaces. If two devices transmit at the same time to the receive of the hub interfaces, the hub repeats both signals at the same time to the transmit of all the other hub interfaces, and both signals received will collide at the transmit of the other interfaces, thus you have a collision where all the other interfaces have garbage signals because it is two signals at the same time. The hosts that are sending simultaneously and hear another signal will realize that more than one is is sending at a time, and they will determine that there is a collision.

Think of it this way, the receive of every hub interface is wired to the transmit of every other interface. Inside the hub, the transmit and receive are connected, even if they are separate at the interface.

Contrast that with a switch, where each link is terminated at the switch interface, and the switch does not have the interfaces wired together. Instead the switch has logic (usually embedded in hardware) to determine where to send frames it receives on one interface, and to prevent collisions inside the switch.

A switch is a high-density bridge. The original bridges were like PCs with multiple interfaces. You would not expect a PC with multiple interfaces to have collisions if it received simultaneous frames on multiple interfaces.

---

Edit:

Your comments lead me to believe you still do not understand what I wrote above about hubs.

The way collisions are detected when using UTP and a hub is by the sending devices hearing another signal while sending. If a device using UTP is configured for half duplex, then it will believe there is a collision when it hears a signal while sending.

When you have a duplex mismatch, the device configured for full duplex will happily send while receiving from the device configured for half duplex. On the other hand, the device configured for half duplex will believe that there is a collision when it is sending and hears that signal from the device configured for full duplex. That will cause all type of problems because the device configured for half duplex will stop sending the frame (causing a runt), and it will send a jamming signal that the device configured for full duplex is not expecting. The device configured for full duplex will then stop sending its frame.

Answer 3

Great question.

In full duplex, there is a dedicated channel for traffic from "left to right" and a dedicated channel from traffic from "right to left":

Therefore, in full duplex, collisions are impossible -- even if both NIC's transmit at the same time.

In half-duplex, however, traffic in either direction is meant to only use the wire, one direction at a time. So while physically, there is still dedicated channels, logically if one NIC receives something while it is transmitting, it logs it as a collision. The bits/signal do not actually "collide" on the wire -- a collision counter is simply incremented when the NIC is Receiving and Transmitting at the same time.

Answer 4

With twisted pair and a repeater hub, the hub is not much more than a digital amplifier. For that it senses a carrier from an incoming signal on one port and switches all other ports to output mode. In this output mode, any additional incoming carrier is a collision. This triggers a jam signal to propagate the collision and make the sender stop transmitting.

This repeating method mimicks the behavior of the previous, shared media Ethernet variants (10BASE5 & 10BASE2) where repeater were only used as physical segment joints or line extenders. Of course you're correct: twisted pair is a full duplex medium on the wire level where a collision only happens on the upper physical layer and not on the wire itself.

A repeater cannot permit more than one sender at the same time. Multiple simultaneous transmissions would mix on the output ports and produce unintelligible noise. Likewise, any node in half-duplex mode assumes a shared medium, incapable of full-duplex transmission. Any carrier sensed while transmitting is a collision, causing the sender to back off. Whether the medium is full-duplex capable (fiber, twisted pair) or not (coax) doesn't matter.

With a duplex mismatch, one link end is in half-duplex mode and the other in full-duplex mode. Now, when the half-duplex (HDX) side is transmitting, any carrier on its receiver causes a collision to be detected. However, the full-duplex (FDX) side may be happily sending away while it is receiving from the HDX side and it is completely oblivious to the collisions that it creates on the far side. The HDX side needs to abort the transmission and sends a jam signal. Since the FDX side cannot detect the alleged collision it detects a partial and therefore damaged frame.

Low-frequency and small frames have a reasonable chance to get through this duplex mismatch, so a ping could actually work. However, as soon as any serious transmission is trying to get under way, the higher frame frequency and larger size will make the transmissions fail very reliably.

With unmanaged switches, a duplex mismatch can be very hard to detect, especially when not even the host NICs report their duplex mode properly.

With managed switches, you usually have port error counters. Increasing collisions on one side (HDX) and increasing runts and FCS errors on the other side (FDX) are very strong indications for a duplex mismatch.

Basically, relying on Auto Negotiation is a very good practice to avoid duplex mismatches. Manually configuring speed and duplex mode is generally prone to creating a mismatch, especially when replacing equipment a few years later on. Fortunately the whole half-duplex scheme went away with Gigabit Ethernet and faster.

Answer 5

Suppose machine A starts sending data to machine B. As the packet begins to be sent, machine C starts sending different data to machine B. There is only one signal path to machine B, so the transmissions from A and C collide and B cannot possibly receive both of them.

The fact that a different circuit is used for transmissions from machine B, to machine A, and to machine C doesn't help. All that's happening is that A and C are trying to transmit to machine B at the same time and there is only one signal path to machine B.